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A  Human  Capital  Crisis  in 
Cybersecurity 

Technical  Proficiency  Matters 

A  White  Paper  of  the 

CSiS  Commission  on  Cybersecurity  for  the  44th  Presidency 


16  July  2010 


based  on  a  body  of  knowledge  that  represents  the  complete  set  of  concepts,  terms 
and  activities  that  make  up  a  professional  domain.  And  absent  such  a  body  of 
knowledge  there  is  little  basis  for  supporting  a  certification  program.  Indeed  it 
would  be  dangerous  and  misleading. 
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A  complete  body  of  knowledge  covering  the  entire  field  of  software  engineering  may 
be  years  away.  However,  the  body  of  knowledge  needed  by  professionals  to  create 
software  free  of  common  and  critical  security  flaws  has  been  developed,  vetted 
widely  and  kept  up  to  date.  That  is  the  foundation  for  a  certification  program  in 
software  assurance  that  can  gain  wide  adoption.  It  was  created  in  late  2008  by  a 
consortium  of  national  experts,  sponsored  by  DHS  and  NSA  and  was  updated  in  late 
2009.  It  contains  ranked  lists  of  the  most  common  errors,  explanations  of  why  the 
errors  are  dangerous,  examples  of  those  errors  in  multiple  languages,  and  ways  of 
eliminating  those  errors.  It  can  be  found  at  http://cwe.mitre.org/top25. 

Any  programmer  who  writes  code  without  being  aware  of  those  problems  and  is  not 
capable  of  writing  code  free  of  those  errors  is  a  threat  to  his  or  her  employers  and  to 
others  who  use  computers  connected  to  systems  running  his  or  her  software. _ 


A  complete  body  of  knowledge  covering  the  entire  field  of  software  engineering  may 
be  years  away.  However,  the  body  of  knowledge  needed  by  professionals  to  create 
software  free  of  common  and  critical  security  flaws  has  been  developed,  vetted 
widely  and  kept  up  to  date.  That  is  the  foundation  for  a  certification  program  in 
software  assurance  that  can  gain  wide  adoption.  It  was  created  in  late  2008  by  a 
consortium  of  national  experts,  sponsored  by  DHS  and  NSA,  and  was  updated  in  late 
2009.  It  contains  ranked  lists  of  the  most  common  errors,  explanations  of  why  the 
errors  are  dangerous,  examples  of  those  errors  in  multiple  languages,  and  ways  of 
eliminating  those  errors.  It  can  be  found  at  http: //cwe.mitre.org/top25. 

Any  programmer  who  writes  code  without  being  aware  of  those  problems  and  is  not 
capable  of  writing  code  free  of  those  errors  is  a  threat  to  his  or  her  employers  and  to 
others  who  use  computers  connected  to  systems  running  his  or  her  software. 
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CSSLP 


The  Certified  Secure  Software  Lifecycle  Professional  (CSSLP)  Certification  Program 
will  show  software  lifecycle  stakeholders  not  only  how  to  Implement  security,  but  how  to 
glean  security  requirements,  design,  architect,  test  and  deploy  secure  software. 

An  Overview  of  the  Steps: 
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(ISC)3  ®  5-day  CSSLP  CBK®  Education  Program 

Educate  yourself  and  (earn  security  best  practices  and  industry  standards  for  the  software  lifecycle  through  the  CSSLP  Education 
Prog  ram,  (I  SC}*  provides  education  your  wav  to  fit  your  life  and  schedule  .Completing  this  course  will,  not  only  teach  a(l  of  the 
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Manually  review  code  after  security  education 

Manual  code  review,  especially  review  of  high-risk  code,  such  as  code  that  faces  the 
Internet  or  parses  data  from  the  Internet,  is  critical,  but  only  if  the  people  perform¬ 
ing  the  code  review  know  what  to  look  for  and  how  to  fix  any  code  vulnerabilities 
they  find.  The  best  way  to  help  understand  classes  of  security  bugs  and  remedies 
Is  education,  which  should  minimally  Include  the  following  areas: 

•  C  and  C++  vulnerabilities  and  remedies,  most  notably  buffer  overruns  and 
Integer  arithmetic  issues. 

•  Web- specific  vulnerabilities  and  remedies,  such  as  cross-site  scripting  (XSS). 

•  Database-specific  vulnerabilities  and  remedies,  such  as  SQL  Injection. 

•  Common  cryptographic  errors  and  remedies. 

Many  vulnerabilities  are  programming  language  (C,  C++  etc)  or  domain-specific 
(web,  database)  and  others  can  be  categorized  by  vulnerability  type,  such  as  injec¬ 
tion  (XSS  and  SQL  Injection)  or  cryptographic  (poor  random  number  generation 
and  weak  secret  storage)  so  specific  training  In  these  areas  is  advised. 


•  A  Process  for  Performing  Security  Code  Reviews,  Michael  Howard, 
IEEE  Security  &  Privacy  July/ August  2006. 

•  .NET  Framework  Security  -  Code  Review; 
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•  Common  Weakness  Enumeration,  MITRE;  http://cwe.mitre.org/ 

«  Sacurity  Cad  a  Reviews  j - 


http://www.codesecurely.org/Wiki/view.aspx/Security_Code  Reviews 
•  Security  Code  Review  Use  Visual  Studio  Bookmarks  To  Capture 
V  Security  Findings;  http://blogs.msdn.com/alikl/archive/2008/01/24/security- 
ajde-revlew-use-visual-studio-bookmarks-to-capture-securlty-findings.aspx 
l^curity  Code  Review  Guidelines,  Adam  Shostack; 

j;//www.  verber.com/mark/cs/security/code-review.html 
\WASP  Top  Ten ,  http  ,7www  awasp.org/index.php/OWASP  Top _Ten_ Project 
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Testing 


Testing  activities  validate  the  secure  Implementation  of  a  product,  which  rei 
the  likelihood  of  security  bugs  coVerfetf  by  customers  afl 

i  :  M|S  users.  TIvj  majority  of  SAFECode  members  have  «dC  f 

software-  security  testing  practices  in  their  software  development  lifecycle.  Thsl 
is  not  to  "test  in  security,"  but  rather  to  validate  the  robustness  and  securB 
the  software  products  prior  to  making  the  product  available  to  customers, 
testing  methods  do  find  security  bugs,  especially  for  products  that  may  net  | 
undergone  critical  secure  development  process  changes. 

Fuzz  testing 

Fuzz  testing  is  a  reliability  and  security  testing  technique  that  relies  on  bu<l _ 

intentionally  maltormed  data  arc  I  software  undei  test  consume  the 

malformed  data  to  see  how  it  responds.  The  science  of  fuzz  testing  is  somewhat 
new  but  it  is  maturing  rapidly  There  is  a  small  market  for  fuzz  testing  tools  today, 
but  in  many  cases  software  developers  must  build  bespoke  fuzz  testers  to  suit  spe¬ 
cialized  file  and  network  data  formats.  Fuzz  testing  is  an  effective  testing  technique 
because  it  uncovers  weaknesses  in  data  handling  code. 


Resources 

•  Fuzz  Testing  of  Application  Reliability,  University  of  Wisconsin; 
http;//pages. cs.wlsc.edu/~bart/fu22/fuzz.html 

•  Automated  Whitebox  Fuzz  Testing,  Michael  Levin,  Patrice  Godefroid  and 
Dave  Molnar,  Microsoft  Research; 

ftp :  //ftp.research .  microsoft.com/pub/tr/TR-2007 -58.pdf 

•  IANewsletter  Spring  2007  "Look  out!  It's  the  fuzz!”  Matt  Wamock; 
http  ://iac.  dtlc.  mil/iatac/download/Vol  1 0_No  1  .pdf 

•  Fuzzing:  Brute  Force  Vulnerability  Discovery.  Sutton,  Greene  &  Amini, 
Addison-Wcsley. 


Fundamental  Practices  for 
Secure  Software  Development 

A  Guide  to  the  Most  Effective  Secure 
Development  Practices  in  Use  Today 

OCTOBER  8, 2008 


Lead  Writer  Michael  Howard,  Microsoft  Corp. 


Contributors 

Gunter  Bitz,  SAP  AG 

Jerry  Cochran,  Microsoft  Corp. 

Matt  Coles,  EMC  Corporation 
Danny  Dhillon,  EMC  Corporation 
Chris  Fagan,  Microsoft  Corp. 

Cassio  Goldschmidt.  Symantec  Corp. 
Wesley  Higaki,  Symantec  Corp. 


Steve  Upner,  Microsoft  Corp. 

Brad  Minnis,  Juniper  Networks,  Inc. 
Hardik  Parckh,  EMC  Corporation 
Dan  Reddy.  EMC  Corporation 
Alcxandr  Seleznyov,  Nokia 
Reeny  Sondhi,  EMC  Corporation 
Janne  Uusilchto.  Nokia 
Antti  Vaha-Sipila,  Nokia 


•  Common  Attack  Pattern  Enumeration  and  Classification,  MITRE, 
http://capec.mitre.org/ 


SAFECode 

1BSUCJ  Driving  Security  and  Integrity 


©2011  MITRE 


a  time-of-cbeck-ti  me-of-use  (TOCTOU)  bug  that  led  to  code  calling  into  a  freed  memory  block.  The 
on  Weakness  Enumeration  (CWE)  classification  for  this  vulnerability  is  C.VE-367. 
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1  Introduction 
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1.2  What  is  Security  Code  Review? 
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**  Preparation** 


Code  review  is  probably  the  single- most  effective  technique  for  identifying  security  flews.  When  used  together  with  automated  tools  end  manual  penetration  testing,,  code  review  can  significantly  increase 
the  cost  effectiveness  of  an  application  security  verification  effort. 

This  guide  does  not  prescribe  a  process  for  performing  a  security  code  review.  Rather,  this  guide  focuses  on  the  mechanics  of  reviewing  code  for  certain  vulnerabilities,-  and  provides  limited  guidance  on 
how  the  effort  should  be  structured  and  executed.  OWASP  intends  to  develop  a  more  detailed  process  in  a  future  version  of  this  guide, 

Manual  security  code  review  provides  insight  into  the  1lreal  risk*  associated  with  insecure  code,  This  is  the  single  most  important  value  from  a  manual  approach,  A  human  reviewer  can  understand  the 

context  for  certain  coding  practices,  and  make  a  serious  risk  estimate  that  accounts  for  both  the  likelihood  of  attack  and  the  business  impact  of  a  breach. 

Why  Does  Code  Hove  Vulnerabilities? 

MITRE  has  catalogued  almost  700  different  kinds  of  software  weaknesses  in  their  CWE  project.  These  are  all  different  ways  that  software  developers  can  make  mistakes  that  lead  to  insecurity,  Every  one 
of  these  weaknesses  is  subtle  and  many  are  seriously  tricky.  Software  developers  are  not  taught  about  these  weaknesses  in  school  and  most  do  not  receive  any  training  on  the  job  about  these  problems, 

These  problems  have  become  so  important  in  recent  years  because  we  continue  to  increase  connectivity  and  to  add  technologies  and  protocols  at  a  shocking  rate.  Our  ability  to  invent  technology  has 

seriously  outstripped  our  ability  to  secure  it.  Many  of  the  technologies  in  use  today  simply  have  not  received  any  security  scrutiny. 

There  are  many  reasons  why  businesses  are  not  spending  the  appropriate  amount  of  time  on  security.  Ultimately,  these  reasons  stem  from  an  underlying  problem  in  the  software  market,  Because 
software  is  essentially  a  black-box,  it  is  extremely  difficult  to  tell  the  difference  between  good  code  and  insecure  code,  Without  this  visibility,,  buyers  won't  pay  more  for  secure  code,  and  vendors  would  be 
foolish  to  spend  extra  effort  to  produce  secure  code, 

One  goal  for  this  project  is  to  help  software  buyers  gain  visibility  into  the  security  of  software  and  start  to  effect  change  in  the  software  market, 

Nevertheless,  we  still  frequently  get  pushback  when  we  advocate  for  security  code  review,  Here  are  some  of  the  (unjustified}  excuses  that  we  hea*-  for  not  putting  more  effort  into  security: 

"We  never  get  hacked  (t hat  I  know  of),  we  don't  need  security  * 
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26736  CVE  Vulnerabilities 
114  Checklists 
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Overview 

SQL  injection  vulnerability  in  mods/banners/navlist.php  in  Clansphere  2007.4  allows  remote 
attackers  to  execute  arbitrary  SQL  commands  via  the  catjd  parameter  to  index. php  in  a 
banners  action, 


Impact 

CVSS  Severity  (version  2.0): 

CVSS  v2  Base  score:  TS  (High)  fAV:N/AC:L/Au:N/C:P/I:P/A:P^  fleaencfl 
Impact  Subscore:  6,4 
Exploitability  Subscore:  10,0 

Access  Vector:  Network  exploitable 
Access  Complexity:  Low 
Authentication:  Not  required  to  exploit 

Impact  Type:  Provides  unauthorized  access,  Allows  partial  confidentiality,,  integrity,  and 
availability  violation  ,  Allows  unauthorized  disclosure  of  information  ,  Allows  disruption  of 
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I  Technical  Details 

Vulnerability  Type  (View  All) 
SQL  Injection  fCWE-39) 


CVE  Standard  Vulnerability  Entry: 

http:  /  /  c  ve.mitre.org/cgi- bin/cvename.cgi?name=CVE- 2007-  5061 
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Common  Weakness  Enumeration 

A  Community-Developed  Dictionary  of  Software  Weakness  Types 


CWE-89  Individual  Dictionary  Definition  (Draft  9) 


^  Failure  to  Sanitize  Data  into  SQL  Queries  (aka  'SQL  Injection') 


Weakness  ID  89  rw«*nesi Base;  Status:  incomplete 

Description  Summary 

The  application  fails  to  adequately  filter  SQL  syntax  from  user-controllable  input. 
This  can  lead  to  such  input  being  interpreted  as  SQL  rather  than  ordinary  user 
data  and  be  executed  as  part  of  a  dynamically  generated  SQL  query.  This  is  a 
specific  form  of  an  injection  problem,  one  that  explicitly  affects  SQL  databases,  in 
which  SQL  commands  are  injected  into  data-plane  input  in  order  to  effect  the 
execution  of  dynamically  generated  SQL  statements. 

Likelihood  of  Very  High 

Exploit 

Common  Confidentiality:  Since  SQL  databases  generally  hold  sensitive  data,  loss  of 
Consequences  confidentiality  is  a  frequent  problem  with  SQL  injection  vulnerabilities. 

Authentication:  If  poor  SQL  commands  are  used  to  check  user  names  and 
passwords,  it  may  be  possible  to  connect  to  a  system  as  another  user  with  no 
previous  knowledge  of  the  password. 

Authorization:  If  authorization  information  is  held  in  a  SQL  database,  it  may  be 
possible  to  change  this  information  through  the  successful  exploitation  of  a  SQL 
injection  vulnerability. 

Integrity:  Just  as  it  may  be  possible  to  read  sensitive  information,  it  is  also  possible 
to  make  changes  or  even  delete  this  information  with  a  SQL  injection  attack. 


Potential  Requirements  specification:  A  non-SQL  style  database  which  is  not  subject  to  this 
Mitigations  flaw  may  be  chosen. 

Design:  Follow  the  principle  of  least  privilege  when  creating  user  accounts  to  a  SQL 
database.  Users  should  only  have  the  minimum  privileges  necessary  to  use  their 
account.  If  the  requirements  of  the  system  indicate  that  a  user  can  read  and 
modify  their  own  data,  then  limit  their  privileges  so  they  cannot  read/write  others' 
data. 


Design:  Duplicate  any  filtering  done  on  the  client-side  on  the  server  side. 
Implementation:  Implement  SQL  strings  using  prepared  statements  that  bind 
variables.  Prepared  statements  that  do  not  bind  variables  can  be  vulnerable  to 
attack. 
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National  Institute  of 
Standards  &  Technology 


The  purpose  of  the  Reference  Dataset  (  ll  )  fs  to  provide  users,  researchers,  and  software  security  assurance  tool  developers  with  a 

set  of  known  security  flaws.  This  will  allow  end  users  to  evaluate  tools  and  tool  developers  to  test  their  methods.  These  test  cases  are 


designs,  source  code,  binaries,  etc.,  i.e.  from  all  the  phases  of  the  software  lire  cycle.  The  dataset  includes  wild  (production),  s 
(written  to  test  or  generated),  and  ‘academic"  (from  students)  test  cases.  This  database  will  also  contain  real  software  applies 
known  bugs  and  vulnerabilities.  The  dataset  intends  to  encompass  a  wide  variety  of  possible  vulnerabilities,  languages,  platfi 
compilers.  The  dataset  is  anticipated  to  become  a  large-scale  effort,  gathering  test  cases  from  many  contributors.  We  have 
about  the  SRD,  including  goals,  structure,  test  suite  selection,  etc. 

Browse,  download,  and  search  the  SRD 

vn  the  tic _ 

NIST 

1  ^  B  Draft  Special  Publication  500-268 

Anyone  can  browse  or  search  test  cases  and  download  selected  cases.  PLease  to  browse  the  test  case  repository;  or 

selected  or  all  test  cases.  To  find  specific  test  cases,  please  lick 
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Table  27.  Most  common  programmin. 

g  errors  found  in  ICS  code* 

Weakness  Classification 

V  u  Ine  r ability  Type 

CWE-19:  Oata  Handling 

CWE-228:  Improper  Handling  of  Syntactically  Invalid  Structure 

CWE-229:  Improper  Handling  of  Values 

CWE-230:  Improper  Handling  of  Missing  Values 

CWE-20:  Improper  Input  Validation 

CWF.-l  16:  Improper  Encoding  or  Escaping  of  Output 

CWE-195:  Signed  to  Unsigned  Conversion  Error 

CWE-198:  Use  of  Incorrect  Byte  Ordering 

CWE'119:  Failure  to  Constrain 
Operations  within  the  Bounds  of  a 
Memory  Buffer 

OWE- 120:  Buffer  Copy  without  Checking  Size  of  Input  (“Classic 

Buffer  Overflow”! 

OWE- 121:  Stack-based  Buffer  Overflow 

OWE*  122:  Heap-based  Buffer  Overflow 

CWE*125:  Out*of~boimds  Read 

C  WE-129:  Improper  Validation  of  Array  Index 

OWE- 131:  Incorrect  Calculation  of  Buffer  Size 

CWE-170:  Improper  Null  Termination 

CWE-190:  Integer  Overflow  or  Wraparound 

CWE-6SO:  Integer  Overflow  to  Buffer  Overflow 

CWE-398:  Indicator  of  Poor  Code 
Quality 

CWE-454:  External  Initialization  of  Trusted  Variables  or  Data  Stores 

CWE-456:  Missing  Initialization 

CWE-457 :  Use  of  Uninitialized  Variable 

CWE-476:  NULL  Pointer  Dereference 

CWE400:  Uncontrolled  Resource  Consumption  ("Resource 

Exhaustion”) 

CWE-252:  Unchecked  Return  Value 

CWE*690:  Unchecked  Return  Value  to  NTJLL  Pointer  Dereference 

CWE-772:  Missing  Release  of  Resource  after  Effective  Lifetime 

CWE-442:  Web  Problems 

CWE-22:  Improper  Limitation  of  a  Pathname  to  a  Restricted  Directory 
(“Path  Traversal”) 

CWE-79:  FaiLure  to  Preserve  Web  Page  Structure  (“Cross-site 

Scripting”) 

CWE'89:  Failure  to  Preserve  SQL  Query  Structure  (“SQL  Injection”) 

CWE-703:  Failure  to  Handle 
Exceptional  Conditions 

CWE-431 :  Missing  Handler 

CWE-248:  Uncaught  Exception 

CWE-755:  Improper  Handling  of  Exceptional  Conditions 

CWE-390:  Detection  of  Error  Condition  Without  Action 

Posted  by  Frank  Kim  on  April  6P  20 1 0  —  3:4 1  pm 
Filed  under  TbplS 

As  requested  here  are  the  links  to  all  the  posts  on  the  Top  25  Most  Dangerous  Programming  Errors.  Hease  let  us  know  if  you 
have  any  suggestions  or  comments. 

1  -  Cross-Site  Scripting  fXSS) 

2  -  SQL  Injection 

3  —  Classic  Buffer  Overflow 

4  -  Cross-Site  Request  Forgery  fGSRF) 

5  -  Improper  Access  Control  (Authorization) 

6  -  Reliance  on  Untrusted  Inputs  En  a  Security  Decision 

7  -  Path  Traversal 

8  -  Unrestricted  Upload  of  Dangerous  File  Type 

9  -  Q5  Command  Injection 

10  -  Missing  Encryption  of  Sensitive  Data 
I  I  -  Hardcoded  Credentials 

\  2  -  Buffer  Access  with  Incorrect  Length  Value 

I  3  —  PHP  File  Inclusion 

14  -  Improper  Validation  of  Array  Index 

1 5  -  Improper  Check  for  Unusual  or  Exceptional  Conditions 

\  £  -  Information  Exposure  Through  an  Error  Message 

17  -  Integer  Overflow  Or  Wraparound 
I  @  —  Incorrect  Calculation  of  Buffer  Size 
i  9  -  Missing  Authentication  for  Critical  Function 

20  -  Download  of  Code  Without  Integrity  Check 

21  -  Incorrect  Permission  Assignment  for  Critical  Response 

22  -  Allocation  of  Resources  Without  Limits  car  Throttling 

23  -  Open  Redirect 

24  -  Use  of  a  Broken  or  Risky  Cryptographic  Algorithm 

25  -  Race  Conditions 
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standard).  Instead,  I'd  like  to  present  an  overview  of  how  the  Microsoft  SDL  maps 

Tags 

to  the  C  WE/SAMS  iist,  just 

CWE 

Title 

Education? 

Manual  Process? 

Tools? 

Threat  Model? 

Common  Criteria  Crawl  Walk 

May. 

20 

Improper  Input  Validation 

Y 

Y 

Y 

Y 

Michael  and  1  have  writte 

116 

Improper  Encoding  or  Escaping  of  Output 

Y 

Y 

Y 

Run  Privacy  SDL  SDL  Pro 

SO 

Failure  to  Preserve  SOI  Query  Structure  (aka  SQL  Injection) 

Y 

Y 

Y 

coverage  of  the  Top  25  ar 

70 

Failure  to  Preserve  Web  Page  Structure  (aka  Cross-Site  Scripting) 

Y 

Y 

Y 

Network  Security  Assurance 

believe  that  the  results  te 

7S 

Failure  to  Preserve  OS  Command  Structure  (aka  OS  Command  Injection)  Y 

Y 

Security  Blacklist  SDL  threat 

25  were  developed  Endepi 
root  them  out  of  the  softv 
analysis  white  paper  and 

310 

Cleartext  Transmission  of  Sensitive  information 

Y 

Y 

352 

Cross-site  Request  Forgery  (aka  CSRF) 

Y 

Y 

modeling 

362 

Race  Condition 

Y 

200 

Error  Message  Information  Leak 

Y 

Y 

Y 

News 

guidance  around  every  m 

119 

Failure  to  Constrain  Memory  Operations  within  the  Bounds  of  a  Memory  Buffer  Y 

Y 

Y 

ma  de  ma  ny  of  the  sa  me  5 

642 

External  Control  of  Critical  State  Data 

Y 

Y 

for  you  to  download  and  t 

73 

External  Control  of  File  Name  or  Path 

Y 

Y 

Y 

About  Us 

426 

Untrusted  Search  Path 

Y 

Y 

Below  is  a  summary  of  he 

04 

Failure  to  Control  Generation  of  Code  (aka  'Code  Injection') 

Y 

Y 

Adam  Shostack 

see  the  SDL  covers  every 
them  (race  conditions  ant 
by  multiple  SDL  requlrem 

404 

Download  of  Code  Without  Integrity  Check 

Y 

Bryan  Sullivan 

404 

Improper  Resource  Shutdown  or  Release 

Y 

Y 

David  Ladd 

Jeremy  Dali  man 

665 

Improper  Initialization 

Y 

Y 

6S2 

Incorrect  Calculation 

Y 

Y 

tools  to  prevent  or  detect 

2S5 

Improper  Access  Control  (Authorization) 

Y 

Y 

Y 

Michael  Howard 

327 

Use  of  a  Broken  or  Risky  Cryptographic  Algorithm 

CWE  Title 

Y 

Y 

Y 

Steve  Lipner 

250 

Hard-Coded  Password 

Y 

Y 

Y 

Y 

732 

I  nsecure  Permission  Assignment  for  Critical  Resource 

Y 

Y 

Blogroll 

20  Improper  Input  V? 

330 

Use  of  Insufficiently  Random  Values 

Y 

Y 

Y 

116  Improper  Encodin 

250 

Execution  with  Unnecessary  Privileges 

Y 

Y 

Y 

BlueHat  Security  Briefings 

Escaping  of  Gutpt 

602 

Client-Side  Enforcement  of  Server-Side  Security 

Y 

Y 

CWE  Outreach:  A  Team  Sport 

May/June  Issue  of  IEEE  Security  &  Privacy... 


CWE-732:  Insecure 
Permission 
Assignment  for 
Critical  Resource 

1  Ye  already  couched  on  chit 
crjl  riinrs  litre,  but  review  .ill : 

ttussionts  and  ACLi  on  all  obj 
you  create  in  the  ilk-  system 
i<m  tip i ration  scum  with  «•. 
Windows  registry.  In  the  cist 
Windows  Vista  and  liter,  d 
change  .my  detaulc  AGL  ui  ilir 
system  or  registry  unless  you 
tend  co  weaken  the  ACL 

CWE-330: 

Use  of  Insufficiently 
Random  Values 

Identity  all  Use  random 
generators  in  vour  code  and  dc 
mine  which,  if  any.  generate  k 
passwords.  iwmji  rv  othersecrel 
Make  sure  die  code  urner.iUng 
ram  Inin  numbers  it  crvptagra| 
C.'illy  random  amt  not  a  deterr 
tttic  generator 

die  G  runtime  rand(}  tunct 
Using  runcttmis  like  rand  ( j 
fine,  hut  not  lor  cryptography 

CWE-250:  Executior 
with  Unnecessary 
Privileges 

Irlemnty  all  pmrrwi  rh.it  i 
part  of  your  solution  and  de 
mine  what  priv rlcgcs  they  req 
to  operate  correctly.  If  a 
rune  jc  root  (on  Linux.  Unix 
M.ic  OS  X)  n»  system  jWrndw 
ask  yourself.  "Whir"  Soineti 
the  answer  is  totally  valid  beta 
the  rode  must  perform  .«  pr 
leged  operation,  but  sumeO 
you  don't  know  why  11  rune 
wav  other  than.  ’T  hat's  the 
its  always  run!*'  If  the  code  d 
need  to  opetate  at  high  ptivil 
keep  the  time  span  within  wl 
tile  code  is  high  privilege  as  si 
as  possible — far  example,  np 
itiy?  j  port  below  1024  in  a  Li 
.ipplu.ftdun  requires  the  code 
be  run  m  root,  but  alter  th.it. 


^JLLJJUI  LltJIk, 
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porrant  th.tt  de 
I  tile  ami  path  d. 
form  before  usi 
cess  a  file  or  p; 
it  net  wlut  cum 
nr  filename.  As 
view,  kink  for 

N  I  Mb  B 
lune  »  appro]: 
cl-i  valid  Jau  K 
and  "known  gn 
Lcllent  way  to  j 

CWE- 426; 
Untrusted 

Old  versions 
searched  the 
nnt  directory 
filenames,  wht 

problems  if  tlx 

had  a  weak  pi 

lulls,  'Si-lf  .1 
aicn’r  conimot 
no  guarantee 
tiun  worfi  use 
scarifies  <ir  sra 
tion  from  a  p\ 
Itused  source, 
environment 
remesiy  is  to 
parts.  Ihk  tins  k 

tenu — for  evai 
Vnta,  die  c:\Pi 
doesn't  oust  u 
vet vi on  of  Wi 
n.iriml  i  'ping 

i  <irtrrt  path  bi 

CWE-94: 
Failure  to 
Generativ 


XSSI  CW.E-79  is  the  real  hug 
that  nukes  CWE-llt»  worse.  In 
the  paw,  we  took  XSS  bogs  light¬ 
ly,  but  now  svr  sev  worms  that  can 
exploit  XSS  vulnerabilities  in  so¬ 
cial  networks  such  as  MySpace  (for 
example,  the  Simv  worm).  Alsu, 
research  into  Web- related  vulner¬ 
abilities  has  progressed  substan¬ 
tially  over  die  past  few  years,  with 
new  ways  to  aiucli  systems  regu¬ 
larly  uncovemi  For  purr  XSS  is¬ 
sue*  as  defined  by  CWE-7‘J.  the 
best  defense  is  to  validate  all  lu¬ 
crum  ng  data.  I  his  has  always  been 
«he  right  approach  and  will  prcii 
ably  continue  to  lie  so  for  the  fore¬ 
seeable  future.  Developers  can  also 
avid  a  Liver  uf  defense  by  encoding 
output  derived  from  untnisced  in¬ 
put  (see  CWE- II 6). 

CWE-7B :  Failure 
to  Preserve  OS 
Command  Structure 

M.irrv  applications,  particularly 
server  applied t ions,  receive  un- 
nrusted  requests  and  we  the  data 
in  them  to  interjct  with  the  un¬ 
derlying  operating  system.  Un- 
fortunately.  this  can  lead  to  severe 
server  compromise  it  the  met  minty, 
data  isn't  analyzed — again,  the  be« 
defense  is  to  cheek  the  data.  Also, 
running  the  potentially  volnrrablr 
application  with  low  privilege  can 
help  umlaut  (lie  damage. 

CWE-3J9:  Cleartext 
Transmission  of 
Sensitive  Information 

Sensitive  dan  roust  obviously  be 
protected  at  rest  and  while  on 
the  uiie  The  bttr  uihuinn  us 
this  vulnerability  it  to  use  a  w<HI- 
tested  technology'  such  »  S&L’ 
I'LS  or  Il’Src  llnti’t  (ever!)  orate 
your  own  commu  rotation  method 
and  cryptographic  defeme.  Thu 
weakness  is  nrlared  to  CWE -327 
f  Uwof  a  broken  or  Risky  Cryp- 
lugr.ipfnc  Algorithm'*),  so  nukr 
sure  you  aren't  using  weak  4<i-bit 
RC4  or  shared-ivy  IPSee 


CWE-352:  Cross-Site 
Request  Forgery 

Crow -sate  request  forgers1  uko 
known  as  CSRF)  vulnerabilities 
are  a  relatively  new  form  of  Web 
steak  new  caused,  in  part,  by  a  bad 
Web  ippln it. mi  design  In  slum. 
(Im  design  doesn't  venfy  that  a  re¬ 
quest  came  from  valid  user  cosle 
and  is  instead  acting  malir  tondy 
on  the  user's  behalf.  Generally, 
the  best  defense  is  to  use  a  unique 
and  unpredictable  key  for  each 
user.  Traditionally,  verifying  input 
doesn't  mitigate  thiv  bug  type  be¬ 
cause  die  input  is  valid. 

CWE-362: 

Race  Condition 

Race  conditions  are  timing  pmb- 
lena  that  lead  to  unexpected 
behavior — for  example,  an  ap- 
p In  at  u>n  too  a  filename  to  veri¬ 
fy  that  a  file  exists  and  then  uses 
the  same  filename  to  open  that 
tile  I  he  problem  is  in  the  mull 
time  delay  between  the  check 
and  the  file  often,  whs:  It  attiuk- 
ers  can  use  to  change  the  file  or 
delete  or  create  it.  The  safest  wav 
to  mitigate  tile  system  race  con¬ 
ditions  i>  to  open  the  object  and 
tlsen  use  the  resulting  handle  for 
further  operations  Also,  con¬ 
sider  reducing  the  scope  of  shared 
objects — for  example  temporary 
files  should  be  local  to  the  user 
and  not  shared  with  multiple  user 
accounts.  Correct  «*e  «>f  synchro¬ 
nization  pnmtttvcs  imutexcx. 
semaphorev.  entreat  sections)  is 
similarly  important 

CWE-209: 

Error  Message 
Information  Leak 

Error  information  b  critical  to  de¬ 
bugging  failed  operations,  bur  rent 
must  undentand  who  can  read 
that  data.  In  general,  vou  should 
revtnet  detailed  error  messages  lo 
trusted  men  Remote  and  auon- 
ynuius  users  should  tec  generic 
messages  with  the  detailed  data 
logged  to  an  audit  lug. 


CWE-119 : 

Failure  to  Constrain 
Memory  Operatim 

The  dreaded  butler 
scourge  oi  C  and  C+S 
1  ity  i  s  p . 
on  uf  kruhthw  than  burl 
nins,  Idie  best  way  to  ecu 
problem  ts  to  move  away 
and  C+f-  wlirre  n  ntaL 
and  use  liigbct-kvcJ  la 
such  as  Ruby,  Ctt,  and  s 
i  aiisc  they  dun  l  .'tfer  dire 
to  memory.  Fot  G  and  G  ’ 
citions.  developers  should 
“known  bod"  functions  su 
C  runtime  (for  example,  i 
stccat,  sxrncpy. 
sprint,  and  getm  and  i 
'<  i  r.  .  ,-M,  |.  Vi-  i.  |  < 
many  weak  AFb  at 
and  you  slum  Id  strive  ti 
compile)  AUo,  furj  tev 
statu.  analysis  can  help  I 
tent!  a.  buffet  DVMflHU. 
opcrating-system-levd 
such  as  address  space  lavs 
dunitzation  and  no  execut 
CtUI  help  reduce  rbc  dram 
buffer  civemm  tt  expiotwb  _ 


CWE- 6 42: 
External  Control 
of  Critical  State  L 

Unprotected  state  infm 
such  as  profile  data  or  ci> 
tormatmn.  is  subject  in  ai 
its  impnrunt  to  protect  t 
by  using  iIk  apprnpnau 
control  lists  (AC,Ls,  or  per 
t<u  |v.TMsmu  slat. i  and  sot 

a  havln-d  message  anthei 

codi  (HMJM  ,  . - 

data.  Vou  can  use  an  HA 
persistent  data  as  well. 

CWE-73: 

External  Control 
of  Filename  or  Pa 

Attackers  night  be  abk-  t 
arbitrary  tile  data  it  they 
die  dan  that's  used  as  pert 
or  path  tunic  It's  u 


It's  cimiiimn  to  see  cudc  injec¬ 
tion  vulnerabilities  ui  Jciv«6crrpt 
cude  that  hutklt  a  string  ilyiumi- 
cally  aral  passes  ii  to  evtil  ( )  to 
I  execute.  If  the  attacker  controls 

I  l he  source  wring  in  any  way.  he  nr 
the  can  crtair  a  malicious  payload. 

1  The  simplest  way'  to  eradicate  this 
kind  of  bug  n  to  eradicate  the  use 
uf  evalU.  but  that  could  mean 
redesigning  the  application. 

£a.axuwrvAPWYACv 


time.  Furr  toi  mp  it  also  ctlecms 
at  detecting C.WE-M>5. 


CWE-682: 

Incorrect  Calculation 

Many  hutfoi  overruns  in  f  am! 

C  ‘  ‘  cede  today  are  actually  re  Lit 
i-d  to  incorrect  burts  r  ur  array -tiae 
(akiiLitimis  it  an  attacker  con¬ 
trols  one  or  more  of  the  eJemetn'  I  the  encryption  key  with 
iu  a  sdc  calculation,  he  or  she  can  |  priare  permhaon 


the  very  least,  look  for  terms  like 
"pwd''  and  "password''  and  make 
sure  you  have  no  hard-coded  pasv- 
woidi  or  secret  dau  ui  the  code. 
You  should  aho  state  this  data  in 
a  sevure  localiiui  within  the  np- 
er.iting  iwtcm.  By  secure,  I  mean 
ptutca  U  with  an  apprupriate  ps:r- 
mission  or  etxrypt  it  and  protect 
appro- 
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Improving  Software  Security 
by  Eliminating  the  CWE 
Top  25  Vulnerabilities 


I 


t)  January  2009.  MITR  E  and  SANS  issued  the  “2009  nx  tiding  Wcb-bjsrd  uuips*  is  a  ilc- 

fonsc  in  case  die  dcvelaper  doesn't 
CWE /SANS  Top  25  Most  Dangerous  Program-  detect  and  prevent  malicious  Web 

input  (s.v  CWE-7*)  and  CWE- 
ming  Errors"  to  help  make  developers  more  aware  2iJ).  However,  die  industry  has  seen 

many  security  bugs  that  could  base 
of  the  bugs  that  can  cause  security  compromises  been  presented  if  the  developer  hsd 


{http://cwcatiicre.org/top25).  I  was  one  ol'  the  many  people 


train  industry,  government,  and 
academia  who  provided  input  to 
tlx-  dsxumcnt. 

CWE.  which  stands  for  Com¬ 
mon  Wcuktirsi  Emimcraiiiai.  is  a 
proifCT  sponsored  by  the  National 
Cyber  Security  Divisxm  cf  tlw  US 
IXpartinenc  of  I  hnnelaml  Sccunty 
to  classify  security  bugs.  It  assigns  a 
unique  number  id  weakness  types 
MH.lt  as  bstrtcr  oscrruits  or  cross-site 
scripting  bup  (for  example.  CWE 
\27  is  "Use  uf  a  l)r< >k.iii  or  Risky 
l  cyptognpliH-  Algonthin”i .  Shnrt- 
Iv  after  die  Top  25  lire's  release. 
Microsoft  unveiled  a  document  en¬ 
titled.  “The  Microsoft  SDL  and  the 
CWE/SANS  Top  25,"  to  explain 
how  Microsoft's  security  processes 
can  help  prevent  the  wont  offend¬ 
ers  (httpt//bfogcinsikicomAdl/ 

arrhivc/2l  lO'J/OI /27/sdl-and-thc 
-cwe-<am-cop-25jupxi. 

Full  disclosure:  Tin  one  of  that 
document  s  coauthors,  but  my  pur 
pose  here  isn’t  to  regurgitate  the 
Mirnxoft  piece  Kachct.  m>  g<ul  is 
to  describe  some  best  practices  that 
can  help  you  clumiuw  the  CWE 
Tup  25  vulnerabilities  in  yout  own 
developnx'iK  environment  and 
prtxlui.iv  It’s  also  iniporurx  tn  un- 
dentand  that  addrvssang  tlw  weak 


CffltJM  HHH>  BV  tt»  fFf  OCWFl  nm  AND  Ml  lAHLITYSOCU TE 


nesses  w  the  list  doesn't  imply 
software  is  secure  from  all 
attack:  there  are  plenty  more  rul- 
nerabilttv  types  to  worry  about! 

CWE-20 :  Improper 
Input  Validation 

Tlir  van  majority  of  w-nous  w- 
cuntv  vulnerabilities  are  input  | 
validation  issnev  boiler 
SQL  injection,  and  cross- 1 
sctipnnij  bugs  cchik  imnicdiatvKj 
iu  mind.  Dcvekipers  simply  mist 
ilie  meonitng  dau  instead  oi  un- 
dertunding  that  they  must  analvzi 
the  itqmt  for  valklity  I  can’t 
this  enough — if  developer*  umplyl 
learned  to  ne 
din  (in  terms  of  format, 
and  size),  many  smous  bugs 
go  aw  .try.  The  core  lesson  here  is  fo 
developers  to  catrfully  validate 
put  and  for  designers  to  understand 
hem  they  can  buikf  dxir  systems 
protect  input  such  that  only  trureci 
ipulue  the  data. 
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The  Web  Application  Security  Consortium 
l^lWrki  [/Pages  &  Files 

VIEW 

Threat  Classification  Taxonomy  Cross  Reference  View 

last  edited  by  tj  Robert  Auger  1G  months,  3  weeks  ago 

Threat  Classification  Taxonomy  Cross  Reference  View' 

This  view  contains  a  mapping  of  the  WASC  Threat  Classification's  Attacks  and  Weaknesses  with  MITRE1  s  Common  Weakness  Enumeration.  METRE'S  Common  Attack  Pattern  Enumeration  and 
Classification.  QWASF  Too  Ten  2010  RC1  (original  mapping  with  OWASP  Top  Ten  from  Jeremiah  Grossman  &  Bill  Corry)  and  SANS/CWE  and  OWASP  Too  Ten  2 Q07  and  2004  (original  mapping 
From  Dan  Cornell,  Denim  Group} 
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SANS/CWE  Top  25 

OWASP  Top  Ten  2010 

OWASP  Top  Ten  2007 

OWASP  Top 

*  Web  Application  Firewall  Evaluation 

Criteria 

*  Web  Application  Security  Scanner 

Evaluation  Criteria 

ID 

2009 

Ten  2004 

WASC-01 

Insufficient  Authentication 

287 

Ml 

A3  -  Broken 

A7  -  Broken 

A3  -  Broken 

Authentication  and 

Authentication  and 

Authentication 

*  Web  Application  Security  Statistics 

Session  Management, 

A4  -  insecure  Direct 

Session  Management, 

A4  -  Insecure  Direct 

and  Session 

management, 

f  Web  Hacking  Incidents  Database 
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Object  References 

Object  Reference 

A2  -  Broken 
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*  Robert  Auder 
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2M 

A4  -  Insecure  Direct 

Object  References,  A7 
-  Failure  to  Restrict 

A10-  Failure  to 
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-  Insecure  Direct 
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*  Rvan  Barnett 
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*  Seraev  Cordevchik 

*  QferShezaf 

URL  Access 

Object  Reference 

*  Brian  Shura 
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128 
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ill  523 
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Transport  Layer 
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WASC  Mailing  Lists 
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Remote  File  Inclusion 

M 

253 
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A3  -  Malicious  File 

Execution 

WASC  on  Twitter 
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Format  Strina 

134 
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Buffer  Overflow 
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10100 
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Overflows 
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Cross-site  ScriDtino 
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79 

A2  -  Cross- Site 
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A4  -  Cross  Site 

/qroups7oid=®3336 

Scripting 

Scripting  (XSS) 

Scripting  (XSS) 

WASC -09 
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3S2 

62 
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IBM  Software 
Technical  White  Paper 


Test  and  vulnerability  assessment 


One  way  to  improve  software  security  is  to  gain  a  better 
understanding  of  die  most  common  weaknesses  dial  can 
affect  software  security.  With  that  in  mind,  there  are  many 
resources  available  online  to  help  organizations  learn  about 


Resources  available  to  help  organizations  protect  systems  in 


Resource 


Focus 


DoD  Information  Assurance 
Certification  ana  Accreditation 
Process  (DIACAFi 


The  DIACAP  defines  the  minimum  stands 
accredited  oy  the  DoD  and  authorized  to 
application -level  security  controls,  but  it  t 
activities,  general  tasks,  and  a  managem 


Testing  applications  for  security  defects  should  be  an  integral  and  organic  part  of  any 
software  testing  process.  During  security  testing,  organizations  should  test  to  help  ensure 
that  the  security  requirements  have  been  implemented  and  the  product  is  free  of 
vulnerabilities. 


The  SEF  refers  to  the  MITRE  Common  Weakness  Enunne  ration  J  (CWE)  list  and  the  Common 


Vulnerability  E 
be  tested.  Thi 
information  ar 
and  vulnerabi 
against  the  m 


Creating  a  se 
plan  includes 

*  For  more  irtforr 
5  For  more  in  torn 


Security  in  Development:  The  IBM  Secure 
Engineering  Framework 


Defers  information  Systems 
Agency  [DISA) 


U.S.  Department  of  Homeland 
Security  [DhSj 


10  Security  in  Development; 

Tie  DISA  provides  a  security  technical  in 
development  that  offer  more  granular  i 

bilily  assessment  techniques.  The  checklist  is  tne  same  one  used  by  DoD  auditors. 


Tie  DHS  offers  information  on  security  best  practices  and  tools  for  appicalion-  and  soft 
part  of  its  "Build  Security  In"  initiative. 


The  Common  Weaknesses 
Enumeration  project,  a 
community-based  pregram 
sponsored  by  the  MITRE 
Corporation,  an  IBM  Business 
Partner 

Tie  MITRE  Corporation  maintains  the  online  common  vulnerabilities  and  exposures  (CVE 
enumeration  (CWE)  knowledge  bases  about  currently  known  vulnerabilities  and  types  of 
knowledge  case  focuses  on  packaged  software  and  deals  with  patches  and  known  vuln 
knowledge  base  focuses  on  code  vulnerabilities. 

The  Open  Web  Application 
Security  Project  (OWASF) 

One  of  the  best  sources  for  information  on  web  application  security  issues,  the  QWASP 
10  list  of  the  most  dangerous  and  most  commonly  found  and  commonly  exp  toiled  vulne 
how  to  identify,  fix  and  avoid  them. 

Digital  Building  Security  In 

Maturity  Model  (BSIMM) 

Created  by  Digital,  an  IBM  Business  Partner,  the  BSIMM  is  designed  to  help  organizatior 
and  plan  a  software  security  initiative,  Tie  focus  is  on  making  applications  more  secure, 
process  and  at  later  stages  in  the  software  life  cycle. 

IBM  X-Foroe™  research  and 
development  team 

A  global  cyberinreal  and  risk  analysis  team  that  monitors  traffic  and  attacks  around  the  < 
IBM  X-Forte  team  is  an  excellent  resource  for  trend  analysis  and  answers  to  questions  £ 
attacks  are  most  common,  where  they  are  coming  from  and  what  organizations  can  do 
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ABSTRACT 

[il  oidei  to  uadi  lI lo  goals  of  dm  Information  Security  Ajlijfnflikjei 
Program  ilSAPj  jli  wc  propose  an  ontological  approach  io 
capturing  and  utilizing  ibe  fimdamciithl  pmeejUa  in  LuCmraalioa 
security  and  ihoit  relationship,  retrieving  vubiciabiliry  data  and 
reasoning  about  the  cause  and  .mpam  of  vulftcraitil  itiea.  Our 
ontology  for  vulnerability  management  (OVM)  has  been 
jKjpiilaitd  with  alt  vulnerabilities  id  NVD  [2,]  with  additional 
inference  rules,  knowledge  representation.  and  data- mining 
ffiEdsflmami.  Watli  the  seamless  integration  of  common 
vubterabtlrtiea  and  their  related  concepts  such  as  -smacks  ajid 
ocMiritciuicasaros,  OVM  provides  a  promising  pathway  to  making 
[SAP  successful. 

Categories  and  Subject  Descriptors 

C.2.0  \  Compncer-Commutiicatiaii  Networks]:  General  [Security 
and  protection],  K1.6.S  [Management  of  Cotuputki  anil 
[u  forms  Lion  Systems  X  Security  and  Protection: 

General  Terms 

Oncology,  Security,  Vulnerability  Analysis  and  Management 

Keywords 

Security  vulnerability.  Sctnamic  technology.  Ontology, 
Vulnerability  analysis 

1.  INTRODUCTION 

The  Jnfomiation.  Security  Atmraiatioii  Program  (LSAP)  h  a  U.S. 
government  multi -agency  initiative  m  enable  automation  and 
standardization  uf  icdntieaJ  security  operation*  []].  Lia  high-level 
go  ale  include  standards  based  auHooMtuu  of  security  checking  arid 
remediation  as  well  as  automation  of  technical  compliance 
activities.  Its  lov.'-kvcl  objectives  include  enabling  standards 
based  communication  of  vulnerability  uaLu.  cuscomkriii^  and 
managing  configuration  baselines  for  various  IT  products, 
assessing  information  systems  and.  reporting  eranpljanee  status, 
using  standard  metrics  to  weight  mid  aggregate  potential 
vuliicrabilLiy  impact,  and  retnediaiing  identified  vulnerabilities  [l  j. 
Sectire  computer  systems  ensure  that  confidentiality,  integrity, 
and  avuilabiliiy  are  maintained  for  uses.  data,  and  other 
information  ausets.  Over  die  past  a  few  decades,  a  significantly 
large  amount  of  knowledge  lias  been  accumulated  in  the  area.  of 
information  security.  However,  a  Lot  of  concepts  in  information 
security  arc  vaguely  defined  and  sometimes  they  have  different 

•PeTmiKiion  t<i  make  digital  -nr  bird  copies  cf  all  or  par  of  this  week  fur 
pccKQi!  it  diKKKKim  ure  is  granLud  without  fee  pnivvdud  b::  ki fries  ire 
rot  rrarv*  uz  diitrifcule-d  far  proRl  lt  c-ammuiTM.1  advantage  ami  that 
copse  bear  this  codec  ami  die  fill]  ciLiticr.  -un  the  first  page.  Tu  copy 
cdicnvisc,  ’.a  republish,  ba  pccL  lt.  -verve n  err  :a  rcdislfributo  tu  Lin:, 
require!  prior  specific  pcnnisHini  and'nca  fw. 
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semantics  in  diffensu  ccnteats,  emusuLg  misuiidcistanduig  among 
stake  holders  due  to  due  language  aiubiguny .  On  the  otiicr  liand, 
die  siandardiEation,  design  and  dovelopmcnt  of  security  tools  [I- 
5]  require  a  systcmaLie  classification  and  dcfinhioti  of  security 
euncepis  and  teehniques.  k  is  important  to  liavu  a  clearly  defined 
vocabulary  and  standardized  language  as  means  to  accurately 
communicate  system  vulnerability  in  formation  and  their 
countermeasures  among  all  tbc  people  involved.  Wc  believe  uiat 
semajLtic  icchnnlogy  in  genetaL  and  ontology  io  particulaj,  could 
be  a  nse-ful  icnjl  foi  system  see  miry.  Our  research  work  has 

L'jufmiiiiJ  lJio  btlkf  hi  id  Li  ir.  paper  w-iil  repe-n  aoiuc  of  oui 

tit  tins  area. 

Ail  ontology  is  a  spccLfleaLion  of  concepts  and  their  telatLonship. 
Ontology  RpfGsots  knowledge  in  a  formal  ami  slnucmred  form. 
There fent,  ontology  provides  a  better  tool  for  communication, 
reusability,  and  organiiation  of  knowledge.  Ontology  is  a 
knowledge  reprcKemuftioii  (K.R)  ayuens  based  on  Description 
Logies  (DLs)  [bX  which  is  an  umbrelLa  name-  fer  a  family  of  KR 
formalisms  nqare waning  knowledge  in  vaiicus  domains.  The  LJL 
formalism  spemiks  a  kunwlcdgc  domain  as  die  "woild"  by  Erst 
defLiiing  die  relevant  concepts  of  die  domain,  and  then  Lt  uses 
those  concepts  in  specify  properties  of  uhjccta  and  individuals 
oceuifnLg  in  tlic  domain  [L  D-L2J.  Scsnantie  tec lutu Logics  not  only 
provide  a  tool  for  oommunLcatioa,  but  alw;  a  foundation  for  high- 
tcvcl  reason  ing  and  dcci  si  on -making.  Ontology-,  in  paflieular, 
provides  ibe-  jiotcniiaL  of  fomial  logit  inference  based  on  vt-cll- 
dcfuicd  data  and  knowledge  bases.  Ontology  captures  the 
relationships  between,  collected  data  and  use  tltc  explicit 
knowledge  of  concepts  and  rdationsiups  to  deduce  die  implicit 
and  inherent  knowledge.  .As  a  matter  of  fact,  a  heavy-weight 
ontology  could  he  defined  as  a  formal  logic  system,  as  h  includes 
faets  and  rules,  concepts,  concept  taxonomies,  relatirHiahipu, 
pOfMrtfea,  ax  ioms  and  coustraents. 

A  vtilnetability  L  a  security  flaw  ,  which  afLies  from  cojnputcr 
system  desL^i,  implementation  mainteiaaiee,  and  operation. 
Research  in  lIu-  an.-j  of  vulncrabiliiy  analysis  focuses  un  discovery 
of  previously  unknown  vulnerabilities  and  quantifkauou  of  the 
sccuriLy  of  aystenjs  according  to  some  metries.  Rescanelicrs  at 
MJTRE  liavL-  provided  a  standard  format  for  naming  a  secutim 
sulner ability,  called  Common  VuJnerabLluies  and  Exposures 
(CVE)  [14].  which  assigns  each  vdlncrabihiy  a  unique 
identification  number  .  We  have  designed  a  vulnerabil  ity  omalogy 
Dv  M  (ontology  for  vulnerability  mauagemcm)  posiuldLud  with  uLI 
existing  vulnerabilities  in  NVD  [2J.  It  supports  tcscareb  on 
reasoning  about  vuLnerabilioes  and  characterization  of 
viLhscrabilitias  and  ifacir  impact  on  couiputing  systems.  Vendors 
and  users  can  use  out  ontology  iu  support  of  '.-uiiLCrabi  liiy 
analysis,  tool  development  and  vulnerabi  lity  management. 

Tlic  test  of  dus  paper  is  ofgauUcd  as  follows:  Section  2  presents 
die  ajchitcetm  e  of  our  OVM.  Seemon  3  discusses  how  to  ]iopnlate 
die  OVM  VriiJi  vulnerability  insLUiccs  from  NVD  und  otbet 


A  Policy-Based  Vulnerability  Analysis  Framework 

By 


SOPHIE  JEAN  ENGLE 
[5.S.  (UiiBvtrsJ.Lv  of  Nebraska  at  Omaha]  2002 

DISSERTATION 

Submitted  in  partial  satisfaction  of  the  requirements  for  ifce  ik^FLt  of 

DOCTOR  OF  PHILOSOPHY 
in 

Computer  Science 
in  the 

OFFICE  OF  GRADUATE  STUDIES 
oILhe 

UNIVERSITY  OF  CALIFORNIA 
DAVIS 

Approved: 


Professor  Mate  Bishop  [Chair;- 


Pm  feasorS.  Felix  Wu 


Pro  Its  so  i  KarS  Ltvitc 


Professor  Seats  PeiserL 

Committee  L a  Charge 
2010 

i 


Making 

Security 

Measurable* 


Analysis- Based  Verification:  A  Programmer- 
Oriented  Approach  to  the  Assurance  of 
Mechanical  Program  Properties 


T.  Jr  Halloran 

May  27:  2GIQ 
CMU-lSR-10-1 12 


InslELLLte  for  Software  Research 
School  of  Computer  Stiuioct 
CanitgK?  MolLtm  L'llivursdty 
Pittsburgh,  PA  15213  " 

Suhm  ititd  in  purtitd  fuljitlmoni  i if  (he  n'-quirvincut-s 
for  the  degree  of  Doctor  of  PhUdntiphy. 


Thesis  CominiU.LL[ 
William  L.  Kdlferlte  (advisor) 
James  D.  Herbs  lob 
Mary  Shaw 

Joshua  ,J.  Bloch;  Clougie.  Im:. 


Copyright  @  2tl  10  T.  J.  Halbran 


TMniiwMiihwj  nt."i.  -mi^  fcy  r|M  rolP»*nt*wn#-  KAB*  ?CC?C*. I!W T«2e  AMCHOAi  takberi  Word*  RAKRS179* 

•S l«l>.  iV$  | V-Kr  h-  I  IV  -3CI0  Tin-  ill  if  PI doc.l'iiv-n  I IimpC i*  iliv ■■  .*.■■  i  ihv>i  i  nd  InCv:  jimwl 

lh  n'nns-xnelsK  dir  ■  >~i  — jl.  poLlon.  ir.ihw  raymcirMl  -sr  nnjiliod  -af  Lhc  kporistar,  Hrf  t  j3.  L'raif rnnumi,  -ar  Ci.r-rfKiB  Mnlliin  Ll.nlhicu-.j  . 


Linkage  with  Fundamental  Changes  in  Enterprise  Security  Initiatives 


Twenty  Critical  Controls  for  Effective  Cyber  Def 
Guidelines 

What  the  20  CSC  Critics  say,„ 

ZD  Critical  Security  Controls  -  Version  2,0 

*  20  Critical  Security  Controls  -  Introduction  (Version  2,01 

■  Critical  Control  1:  Inventory  of  Authorized  and  Unauthorized 

*  Critical  Control  2:  Inventory  of  Authorized  and  Unauthorized 
-  Critical  Control  3:  Secure  Configurations  for  Hardware  and  Sc 

Servers 

*  Critical  Control  4:  Secure  Configurations  for  Network  Devices 

*  Critical  Control  5:  Boundary  Defense 

■  Critical  Control  6:  Maintenance,  Monitoring,  and  Analysis  of  j 

■  Critical  Control  7:  Application  Software  Security 

■  Critical  Control  8:  Controlled  Use  of  Administrative  Privilege 

■  Critical  Control  9:  Controlled  Access  Based  on  Need  to  Know 

■  Critical  Contrc' 


Critical  Contrt 
Critical  Contrt 
Critical  Contrt 
Critical  Contrt 
Critical  Contrt 
Critical  Contrt 


Critical  Contrt 
Critical  Contrt 
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CAG:  Critical  Control  7:  Application  Software  Security 

« previous  control 


Consensus  Audit  Guidelines 


next  control  5 


How  do  attackers  exploit  the  lack  of  this  control? 

Attacks  against  vulnerabilities  in  web-based  and  other  application  software  have  been  a  top  priority  for  criminal 
organizations  in  recent  years.  Application  software  that  does  not  properly  check  the  size  of  user  input,  fails  to 
sanitize  user  input  by  filtering  out  unneeded  but  potentially  malicious  character  sequences,  or  does  not 
initialize  and  clear  variables  properly  could  be  vulnerable  to  remote  compromise.  Attackers  can  inject  specific 
exploits,  including  buffer  overflows,  SQL  injection  attacks,  and  cross-site  scripting  code  to  gain  control  over 
vulnerable  machines.  In  one  attack  in  Z008,  more  than  1  million  web  servers  were  exploited  and  turned  into 
infection  engines  for  visitors  to  those  sites  using  SQL  injection.  During  that  attack,  trusted  websites  from  slate 
governments  and  other  organizations  compromised  by  attackers  were  used  to  infect  hundreds  of  thousands  of 


Procedures  and  tools  for  implementing  t 


CWE  and  CAPEC  included  in  Control 
7  of  the  “Twenty  Critical  Controls  for 
Effective  Cyber  Defense:  Consensus 
Audit  Guidelines” 


Source  code  testing  tools,  web  application  security  scanning  tools,  and  object  code  testing  tools 
have  proven  useful  in  securing  application  software,  along  with  manual  application  security 
penetration  testing  by  testers  who  have  extensive  programming  knowledge  as  well  as 
application  penetration  testing  expertise.  The  Common  Weakness  Enumeration 


Critical  con-  initiative  is  utilized  by  many  such  tools  to  identify  the  weaknesses  that  they  find.  Organizations 
can  also  use  CWE  to  determine  which  types  of  weaknesses  they  are  most  interested  in 
addressing  and  removing.  A  broad  community  effort  to  identify  the 

is  also  available  as  a  minimum  set  of  important  issues  to  investigate  and 


address  during  the  application  development  process.  When  evaluating  the  effectiveness  of 
testing  for  these  weaknesses,  the  Common  Attack  Pattern  Enumeration  and  Classification 
((  APEC)  can  be  used  to  organize  and  record  the  breadth  of  the  testing  for  the  CWEs  as  well  as  a 
way  for  testers  to  think  like  attackers  in  their  development  of  test  cases. 


Linkage  with  Fundamental  Changes  in  Enterprise  Security  Initiatives 


*  Technical  Interoperability-  The  ability  for  different  technologies  to  communicate  and 
exchange  data  based  upon  well  defined  and  widely  adopted  interface  standards. 

*  Policy  Interoperability.  Common  business  processes  related  to  the  transmission,, 
receipt,  and  acceptance  of  data  among  participants. 

Within  cyberseeurity,  all  three  types  of  interoperability  are  being  enabled  through  an  approach 
that  has  been  refined  over  the  past  decade  by  many  in  industry,  academia,  and  government.  It 
is  an  information-oriented  approach,  gen  era  lly  referred  to  as  [cyber]  security  content 
outt?mat™  and  comprises  the  following  elements.13 


Enabling  Distributed 
Security  in  Cyberspace 


Building  a  Healthy  and  Resilient  Cyber 
Ecosystem  with  Automated  Collective  Action 
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*  Enumerations.  These  are  lists  or  catalogs  of  the  fundamental  entities  of  cybersecurity,, 

for  example,  cyber  devices  and  software  items  (CPE)'  device  and  software  _ 

"imessesm  architecture,  design,  orco de 
E);  or  pubf idy  k  now  n  attach  pattern. ;  (CAPEC  i , 
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Forums 

The  Software  Assurance  Program  of  the  Department  of  Homeland  Seouri 
Cyber  Security  Division  co-sponsors  SwA  Forums  semi-annually  with  org 
Department  of  Defense  and  the  National  Institute  for  Standards  and  Ted 
purpose  of  the  forums  is  to  bring  together  members  of  government,,  Indt 
academia  with  vested  interests  in  software  assurance  to  discuss  and  proi 
security,  and  reliability  in  software. 


SwA  Market  Place 


SwA  Landscape 


SwA  Ecosystem 
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FORUM  PRESENTATIONS 

5wA  Forum  presentations  that  are  released  for  publication  arc  posted  he 
I3in  Semi-Annual  software  Assurance  Forum  -  September  27-october  t, 
iZLh  Semi-Annual  Software  Assurance  Fgrum  -  March  9-12,,  2010 
llth  Semi-Annual  Software  Assurance  Forum  -  November  3-5,  2009 
ifMSh  Semi-Annual  Software  Assurance  Forum  -  March  ID- 12,  2009 
9th  Semi-Annual  Software  Assurance  Forum  -  October  14-16,,  2008 

SWA  WORKING  GROUPS 

in  between  SwA  Forums,  the  DHS  SwA  Program  hosts  SwA  Working  Groi 
provide  venues  for  public- private  collaboration  in  advancing  software  ass 
initiatives,  and  status  updates  from  the  SwA  Working  Groups  arc  presenl 
Forums  and  to  other  relevant  stakeholder  groups.  For  more  information 
WG  sessions,  see  the  Events  page  on  Build  Security  in, 

+  June  21-23,  20lD  Working  Group  Session  Agenda  and  Presentations 
*  December  14- Id,  20 ID  Working  Group  Session  Agenda  and  Presents 

Learn  more  about  SwA  Forums  and  Working  Group  Sessions  or  downloat 
arid  Working  Group  Scssrons  Fact  Sheet  and  Frequently  Asked  Questions 
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